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1.  SCOPE  AND  PURPOSE 


y  This  specification  describes  the  Protocol  Test  System  and  the  program 

functions  of  the  File  Transfer  Protocol  (FTP)  Remote  Driver  (RD).  Section  2, 
''""The  Protocol  Test  System,  summarizes  the  testing  procedures  used  by  the 
Protocol  Test  System"'' contains  guidelines  for  developing  and  FTP  RD  on  a  host 
where  an  implementation  under  test  resides.  The  role  of  the  FTP  RD  in 

protocol  testing  is  also  defined. 

\ 
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2.  THE  PROTOCOL  TEST  SYSTEM 


2. 1  TEST  TOOLS 

The  major  components  of  the  Protocol  Test  System  are: 

o  The  test  Scenario  Language  -  To  enable  a  tester  to 
specify  standardized  scripts; 

o  The  Scenario  Language  Compiler  and  Libraries  - 
To  produce  code  for  automated  testing; 

o  The  Protocol  Reference  Implementation  —  To  define 
standard  functions  for  the  level  being  tested;  and 

o  The  Drivers  —  Central,  Surrogate,  Slave,  and  Remote 

—  To  execute  tests  and  to  provide  communication  links. 

This  test  system  causes  an  IUT  to  perform  protocol  exchanges  with  a  reference 
implementation.  To  generate  reproducible  results,  a  script  controls  the 
driver  that  controls  each  IUT  through  its  upper  level  interface.  A  complete 
test  executes  several  scenarios  of  prescribed  actions  that  exercise  one  or 
more  protocol  features. 

2.2  GENERAL  REQUIREMENTS  OF  THE  CENTRAL,  SURROGATE,  SLAVE,  AND 
REMOTE  DRIVERS 

The  Central  Test  Driver  (CTD),  which  coordinates  and  monitors  protocol 
testing,  combines  the  Surrogate  and  Remote  Driver  results  to  determine  the 
success  or  failure  of  each  implementation.  The  Surrogate  Driver  provides  the 
transport  mechanism  between  the  CTD,  the  Slave,  and  the  Remote  Drivers. 
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3.  REMOTE  DRIVER  DESIGN  AND  PROTOCOL  TESTING 

The  following  sections  describe  the  Remote  Driver  design  and  explain 
how  all  drivers  interact  to  communicate  protocol  commands  or  responses  in 
Protcol  Test  System  testing. 

3.1  THE  COMMAND  CHANNEL 

All  drivers  except  the  RD  reside  at  the  Protocol  Test  System  site. 

The  Remote  Driver  operates  as  a  background  process  using  a  Transport  protocol 
level  connection,  which  links  the  RD  at  a  remote  site  with  the  laboratory 
drivers  and  the  reference  and  IUT  protocols. 

To  set  up  the  command  channel,  the  RD  sets  up  a  passive  listen  on  a 
well-known  port  and  waits  for  the  Surrogate  Driver  to  perform  an  active  open 
on  that  port.  The  command  channel  is  ready  when  the  Transport  connection  to 
the  Remote  and  Slave  Drivers  has  been  established,  and  all  drivers  have 
initiated  communications  with  their  respective  protocols.  Figure  1  Is  a 
diagram  of  connection  establishment,  and  Table  1  below  gives  destinations  and 
port  numbers. 


Table  1.  Destinations  and  Port  Numbers 


Destination 

Port  Number 

RD  Passive  Open  Port 

1204 

IUT  Server  FTP 

21 

Passive  Open  Port 
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3.2  FLOW  or  COMMANDS 


lumbers  representing  protocol  co«ands  crtvil  over  the  command  cnannel 
from  the  Central  Driver,  through  the  Surrogate  Driver,  to  the  Slave  and  Remote 
Drivers  (Figure  2,  p.  3-3;  Table  3,  p.  3-9).  The  Slave  and  Remote  Drivers 
translate  these  numbers  Into  the  appropriate  commands,  then  Issue  the  com¬ 
mands.  Similarly,  responses  from  the  reference  and  IUT  protocols  are  received 
by  the  Slave  and  Remoee  Drivers  and  forvarded  over  the  command  channel  to  tr.e 
Surrogate  and  Central  Drivers.  CTD  determines  from  the  combined  test 

responses  whether  the  IUT  has  functioned  properly  and  reacts  accordingly  —  by 
taking  the  next  appropriate  action  In  the  testing  process  —  and  the  flow  of 
commands  Is  rapeatsd. 


Transport  Connection 


Transport  Connection 


(background  process) 


Interprocess 

Communication 


Figure  l.  Connection  Establishment 
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3.3  INPUTS  AND  OUTPUTS 


Daca  is  transmitted  between  the  Protocol  Test  System  Central  Driver 
and  the  Remote  Driver  in  blocks  called  packets.  The  laboratory  implementation 
of  the  Remote  Driver  uses  a  PAD  (Packet  Assembler/Disassembler)  function  to 
control  the  input  and  output  of  such  packets. 

The  Remote  Driver  must  be  able  to  send  and  receive  pne  of  three 
packets:  an  ACK  (Acknowledgment),  a  NAK  (Negative  Acknowledgment),  or  a  data 
packet  containing  either  protocol  responses  or  driver  command  results.  Figure 
3  (p.  3-5)  shows  the  generic  format  of  the  data  packet;  Figure  C.2  in  Appendix 
C  defines  a  typical  data  packet  in  C  syntax. 

3.3.1  The  Control  Flag  Field 

A  single  octet  contains  the  control  flag,  which  indicates  by  bit 
position  how  the  Remote  Driver  should  interpret  the  rest  of  the  data  packet. 
The  bit  positions  are  in  ascending  order  from  right  to  left,  as  in  a  DEC 
(Digital  Equipment  Corporation)  VAX.  Figure  U  (p.  3-6)  diagrams  the  bit 
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Concrol  Flag. 


bie  positions 

Flgura  i.  Tha  Sic  Drdar  of  a  Syca 


Tabla  2  sumaarlzas  cha  conf lguracion  of  ble  positions  Ln  cha  control 
flag.  Only  bit  positions  0,  1,  and  2  irt  ussd.  Tha  RD  sacs  cha  btc  ln  posi¬ 
tion  0  to  on*  (1)  co  lndlcaet  chat  an  ACK  packae  Is  balng  ssnc.  A  zaro  (0)  In 
:nis  position  lndlestss  a  NAJC.  If  cha  RD  sacs  cha  ble  in  posleion  1,  chan. a 
data  packae  (as  opposad  co  an  aCK/ VAX  packae)  Is  bain*  sane.  Saeelng  cha  DATA 
ble  ln  a  packae  could  signal  stchar  chae  cha  RD  is  sanding  a  protocol  ra- 
sponsa,  or  chae  lc  Is  sanding  cha  rasuics  of  ona  of  lea  own  drlvar  oparaeiona, 
such  as  comparing  cvo  filas.  In  a  flla  comparison,  cha  daea  Is  a  characesr 
scrlng  containing  cha  words  "succass"  or  "failura.”  Tha  ble  in  postcion  I  of 
: •«  first  ocesc  of  sacn  daea  oackac  sane  by  cha  CTO  -iscsrminas  whachar  cha 
packs c  contains  a  protocol  or  a  drlvar  command. 


Tabia  2.  31c  Positions  in  cha  Concrol  "lag 


Error  flags  will  explain  che  naeure  of  an  trror  occurring  ac  che  Remoc 
Driver.  Because  arror  codas  ara  noc  yet  Implemented,  cha  Protocol  Tasc  Svsce 
aakas  no  aceaapc  to  lncarprac  this  flald. 

3.3.3  The  Prlalclva  Coda  Flald 

Tha  prlalclva  coda  flald  can  ba  Intarpratad  In  ona  of  two  ways  — 
either  as  a  protocol  prlalclva  coda  or  as  a  drlvar  Drialclva  coda.  K  prlai- 
clva  In  this  sansa  aaans  a  command  chat  daserlbas  soaa  action  within  cha 
protocol  or  cha  drlvar. 

3.3.3. 1  Tha  Protocol  Prlalclva  Codas 

If  cha  control  flag  indlcacas  a  protocol  command  (l.a.,  cha  bit  In 
position  2  Is  sec  co  l),  chan  cha  Remote  Drlvar  muse  translate  cha  Integer  In 
the  coda  field  co  Its  corresoonding  protocol  prlalclva  according  co  cha 
descriptions  and  cha  coda  nuabers  In  Table  3  (p.  3-9).  What  fora  of  data  che 
HD  sands  co  che  protocol  tUT  depends  on  cha  Id's  User  Interface,  buc  che  RD 
oust  Include  this  translation  capability  In  Its  function.  To  pass  quali¬ 
fication  testing,  an  FTP  Id  must  ba  able  co  perform  all  che  ori.as.cive  action 
described  in  Table  3. 

Tha  Remote  Driver  determines  whether  arguments  are  associated  wicn  a' 
primitive  according  co  its  protocol  Id.  If  arguments  ara  required  for  a 
given  primitive,  they  must  ba  supplied  In  cha  "eexc"  flald  of  cha  daea  packec 
If  such-  arguments  ara  not  supplied,  than  an  arror  condition  occurs  and  cha  RD 
muse  SAX  chac  packet. 

Tha  RD  can  determine  whether  cha  required  arguments  ara  present  bv 
reading  cha  "num  bytes"  flald,  which  calls  how  many  bytes  of  character  ASCII 


data  are  la  eh#  "etxc"  fl«ld.  If  chi*  field  contains  a  taro,  ch#n  ch#  V  nav 
assume  no  arguments  hava  Saan  supplied.  However,  If  eha  "nua^bycea"  flaid 
contains  any  positive  lncagar  fro*  1  to  4096,  cha  HD  suse  raid  eha  concents  of 
cha  "text"  flaid  and  lnearprae  chasa  coneanes  at  ch*  primitive's  arguments. 

An  lncagar  oueslda  eha  rang*  of  l  co  4096  Mans  eha  packet  Is  In  arror,  and 
ehac  a  .VAX  packae  should  b«  raeurnad. 

In  Tabla  3  eha  primitive  comands  and  number  codas  ara  follovad  hv  one 
or  aora  argument  fields.  Prlalelva  naais  ara  five  or  favar  alphabaclc 
characters,  and  upper-  and  Lowercase  characters  for  boeh  primitives  and 
arguMnes  ara  created  Identically.  One  or  more  ASCII  spaces  separata  eha 
prlalelva  cod*  and  eh*  argument  field,  which  conslses  of  a  characear  string 
whose  variable  length  is  specified  in  eh*  nu*_byces  flaid.  (S«eclon  5.7,1  of 
MIL-STD-1 780  describes  FTP  commands  fureh*r.)  Three  hyphens  (-— )  In  ch# 
table's  "arguments"  column  Indicate  ehat  none  exist. 
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Prinitlve 
(So.  Code) 

Argument 

FTP  I’JT  Action 

user 

(i) 

usernaae 

-  Causes  the  User  FTP  to  send  the  USER 
command  over  the  command  connection.  The 
argument  field  is  the  user  Identification 
required  by  the  server  for  access  to  its 
file  system. 

pass 

(2) 

password 

-  Causes  the  User  FTP  to  send  the  PASS 
coaaand  over  the  coaaand  connection.  The 
argument  field  identifies  the  user's 
password. 

acct 

(3) 

account_inf o 

-  Causes  the  User  FTP  to  send  the  ACCT 
comaand  over  the  connand  connection.  ”ve 
argument  field  identifies  the  user's 
account.  In  most  cases  this  information 
is  optional  and  host  specified. 

rein 

(4) 

-  Causes  the  User  FTP  to  send  the  REIN 
command  over  the  command  connection: 
Reinitialises  the  FT?  session;  finishes 
all  pending  transactions;  then  returns 
the  FTP  to  its  default  state. 

:ui: 

;5) 

— — 

-  Terminates  a  USER  and.  if  file  transfer 

is  not  in  progress,  the  Strvtr  closes  tr.e 
command  connection  and  exits.  C T’n t s 
sotclf icatlon  differs  from  MIL-STD-i *80 , 
wnich  does  not  require  the  Server  to 
exit.  See  the  following  descriotton  or 
the  clos  primitive.)  If  file  transfer  . s 
in  progress,  the  Server  will  close  the 
connection  after  result  response.  If  t-e 
User  Data  Transfer  Process  (DTP)  Is 
transferring  files  for  several  US ERs  Out 
prefers  not  to  close  and  then  reooen 
connections  for  each,  then  the  REIN 
comaand  should  be  used  instead  of  XI T. 


fable  3. 


Protocol  Primitive  Commands ,  Number  Codes,  and  Arguments, 
with  Consequent  FTP  I’JT  Action  (Page  2  of  8 ) 


Primitive 
(So.  Coda) 


Argument 


quit  (5) 
(continued) 


c  1  os  (6) 


host  [port] 


xoort  (7) 


oasv  '8) 


type  (9) 


:ype  code 


FTP  ITT  Action 


An  unexpected  close  on  a  command  connec¬ 
tion  will  cause  the  Server  to  cake  the 
effective  action  of  an  abort  (ABOR)  a-:  i 
logout  (QUIT). 


Terminates  the  User  FTP  session  with  the 
specified  hoec  FTP  Server,  but  does  not 
exit.  (The  cloe  primitive  Is  the  same  as 
the  quit  primitive,  but  without  the 
exit.)  An  optional  ourt  number  may  be 
supplied;  If  so,  the  "ser  FTP  will  cry  to 
terminate  the  session  with  the  FTP  Server 
at  chac  port. 


Causes  the  Cser  FTP  to  send  an  FTP  PCRC 
command  on  the  current  command  connec¬ 
tion.  The  host  and  port  argument  for  : 
FTP  PORT  command  Is  obtained  bv  first 


Issuing  a  PASV  command. 
5.7.2  of  MIL-STD-1730.) 


[See  Section 


Causes  the  Cser  FT?  to  send  the  PASV 
command  over  the  command  connection. 

This  command  reouescs  the  Server  to 
"listen"  on  a  data  por*  (not  Its  default 
data  sort)  and  to  wale  for  a  connection 
rather  chan  to  Initiate  one  upon  receiot 
of  a  transfer  command.  The  response  to 
the  PASV  command  includes  the  host  and 
oort  address  on  which  the  Server  Is 
listening. 


Causes  the  Cser  FTP  to  send  the  TYPF 
command  over  the  command  connection.  71 
argument  indicates  the  data  represen¬ 
tation  type  as  specified  In  the  Section 
on  Data  Representation  and  Storage  In 
MIL-STD-1780. 


"T* 
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Table  3.  Protocol  Primitive  Commands,  dumber  Codes,  and  Arguments, 
vitn  Consequent  FTP  ITT  Action  (Page  3  of  8) 


Primitive 

(So.  Coda) 


Argument 


FTP  ITT  Action 


sera  ( 10) 


struct  code 


mode  (11) 


■node  coda 


racr  (12) 


oathna: 


Cauaes  the  Cat r  FTP  to  sand  the  STPC 
command  ovar  tha  command  connaccton. 
Indicata*  Che  seruccuca  of  tha  fila  belr.* 
transferred.  Tha  arguaanc  specifies  a 
scructura  of  fila,  page,  or  racord.  (See 
Section  5.7.2  of  (HI.-STD-1780. ) 

Causes  cha  Uaar  FTP  to  sand  cha  MODE 
command  ovar  cha  command  connaction. 
Indicacas  cha  transmission  mode  of  cha 
fila  being  tranafarrad.  Tha  arguaanc 
spacifiaa  cha  daca  transfer  mo da  of 
screaa,  block,  or  coaorassad.  (See 
Saction  5.7.:  of  -IL-STD-i 730 . ) 

Causes  tha  Tsar  FTP  to  sand  cha  PITS 
command  over  tha  command  connection. 

This  command  causes  the  Server  to  ini¬ 
tiate  tha  transfer  of  a  coov  of  the  file, 
specified  in  tha  pathname  argument,  to 
the  Server  or  tne  Tsar  over  tne  daca 
connection. 


>  to  r  13) 


pathname 


Causes  the  Tser  FT?  to  sand  t-e  5TCR  com¬ 
mand  over  the  command  connection.  This 
command  causes  cha  Server  to  accent  the 
data  transferred  over  the  daca  connection 
and  to  score  the  data  as  a  file,  soeci- 
fied  in  the  pathname  argument,  at  the 
Server's  site. 


aopa  ( 14) 


pathname 


Causas  tha  Tsar  FTP  to  sand  tha  aPPS 
command  ovar  the  command  connection. 

This  command  causas  tha  Server  to  accept 
tha  daca  transferred  over  cha  daca  con¬ 
nection  and  to  store  cha  daca  in  a  file, 
specified  bv  cha  pathname  argument,  at 
tha  Server  site.  If  no  such  flit  e-cists. 
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Table  3.  Pro  t  oco  1  Primitive  Commands,  .Vumber  Codes,  and  ArguMr.:s, 
with  Consequent  FT?  ITT  Action  (Page  -  of  3) 


Primitive 

(No.  Coda) 

Argument 

FT?  ITT  Action 

aop«  (  14) 

( continued ) 

alio  (15) 


(  16) 


to 


:  17) 


abor  ' 18) 


pathname  than  a  new  fila  is  craacad  at  tha  Server 

slca. 

deciaal^int  -  Causas  tha  '.’sar  FT?  to  sand  tha  aLTD  coa- 

[R  declmai_int]  mend  ovar  tha  command  connaction.  Causes 
tha  Sarvar  to  reserve  sufficient  storage 
to  accomodate  tha  nav  file  to  ba  trans¬ 
ferred.  Tha  argument  indicates  tha  num- 
bar  of  bvtas  to  ba  resarvad.  This  corn- 
sand  say  not  ba  required  by  thoaa  Servers 
that  require  no  prior  declaration  of  max¬ 
imum  file  size,  and  should  ba  treated  as 
a  VOOP  in  such  cases.  (Sea  Section 
in  *IL-STO-1780  for  complete  require¬ 
ments.  ) 

pachnatne  -  Causas  the  L’sar  FTP  to  sand  the  P.VFP 

command  over  the  command  connection. 

This  command,  whic.n  identifies  tne  file 
to  ba  renamed  using  tha  pathname  argu¬ 
ment,  must  ba  followed  lamediatelv  pv  a 
’'rename  to"  command  (PNTC)  soecifvt-.j  :~e 
new  file  pathname. 

pathname  -  Causas  the  L'sar  FT?  to  send  the  ^N'TC  com¬ 

mand  over  the  command  connection.  T-is 
command  specifies  the  new  oatnnane  of  ;~e 
file  identified  in  tne  intnedlacelv  ore- 
ceding  "rename  from"  coraaand.  Together, 
the  two  commands  cause  a  file  to  oe  re¬ 
named. 

— -  -  Causas  tha  I'ser  FTP  to  sand  t'-e  A301? 

command  over  tha  command  connaction. 

This  command  cells  the  Server  to  aoort 
the  orevious  FTP  service  command  and  arv 


mrr  * 


m 

A*T 

I'A*! 


able  3.  Protocol  Primitive  Comands,  Number  Codes,  end  Arguments 
ur  t.n  Consequent  FTP  I’.T  Action  (Page  5  of  3) 


Primitive 
Ho.  Coda) 


abor  ( 18) 
l continued ) 


Argument 


oachnaa 


owd  20) 


oachname 


associated  transfer  of  data.  The  abort 
cotaaand  requires  special  action  to  fort 
recognition  by  the  Server,  as  discussed 
In  cbie  MIL-STD-1780  section  on  FT?  com¬ 
mands.  So  action  Is  to  be  taken  if  tne 
previous  comand  has  been  completed 
(including  data  transfer).  The  TELNET 
connection  Is  not  to  be  closed  by  the 
Server,  but  the  data  connection  -oust  be 
closed.  When  this  command  Is  received, 
there  are  two  cases  for  the  Server:  tn« 
FTP  service  command  was  already  comole- 
ted,  or  the  FT?  service  command  is  still 
in  progress.  In  the  first  case,  tne 
Server  closes  the  data  connection  if  : : 
is  open),  and  responds  with  a  IIS  reol/ 
indicating  the  abort  command  was  success 
fully  orocessed.  In  the  second  case, 
Server  aborts  tne  FTP  service  in  orogrss 
and  closes  the  data  connection,  re  turn i- 
a  -*25  redy  to  indicate  abmr-al  service 
reouest  termination.  The  Server  tne" 
sends  a  226  reolv  to  indicate  t~e  acor: 
command  was  successfully  orocessed. 

Causes  the  User  FT?  to  send  tne  2F.LE 
coanand  over  the  command  connection. 

This  command  causes  cne  file  soecifieo  : 
the  oathnarae  argument  to  he  deleted  at 
the  Server  site.  If  an  extra  level  o: 
orotecclon  is  desired,  it  snould  :e 
provided  bv  the  ,'ser  FT?  orocess. 

Causes  the  L'ser  FT?  to  send  tne  T-T  com¬ 
mand  over  the  command  connection.  T'-is 
command  allows  the  user  to  wont  wit'  a 
different  director/  or  dataset  tor  rile 


P 
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Table  3. 


Protocol  Primitive  Commends,  dumber  Cades,  and  Arguments, 
with  Consequent  FT?  ITT  Action  CP age  6  of  8) 


Primitive 
( Wo.  Code) 


Argument 


evd  (20) 
(continued) 


pathname 


list  (21) 


pathname 


'.1st  22) 


oathname 


FT?  IT*  Action 


storage  or  retrieval  without  altering  >is 
login  or  accounting  Information.  The  ar¬ 
gument  Is  a  pathname  specifying  a  direc¬ 
tory  or  ocher  system-dependent  file  grouo 
designator. 


Causes  the  I'ser  FTP  to  send  the  LIST 
command  over  the  command  connection. 

This  command  causes  a  list  to  be  sent 
from  the  Server  to  the  Passive  Data 
Transfer  Procase  (DTP).  If  the  pathname 
specifies  a  directory,  the  Server  should 
transfer  a  Use  of  flies  In  che  soeciflep 
dlrectorv.  If  the  pathname  specifies  a 
file,  then  the  Server  should  send  current 
Information  on  che  file.  A  null  argument 
implies  the  user's  current  wonting  or 
default  dlrectorv.  ”he  data  transfer  i3 
over  the  data  connection  in  tvoe  ASCII  or 
£30  IC. 


Causes  the  ’.’ser  FT?  to  send  the  VLST 
command  over  tne  command  connection. 

This  command  causes  a  director/  listing 
to  be  sent  from  the  Server  to  the  Jser 
site.  The  pathname  should  soeclfy  a 
directory  or  other  system-deoenaent  file 
group  descriptor,  a  null  argument  im¬ 
plies  the  current  dlrectorv.  The  Server 
returns  a  scream  of  filenames  and  no 
other  Information.  The  data  is  trans¬ 
ferred  in  ASCII  or  E3CDIC  tvoe  over  the 
data  connection  as  valid  oathname  strings 
separated  by  Carriage  Peturn-Linefeed 
(<CRLF>)  or  Vewltne  (<XL>).  The  user 
must  ensure  the  TYPE  is  correct. 
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Table  3.  Protocol  Primitive  Commands ,  Number  Codes,  and  Argaaar.es, 
with  Consequent  FTP  IU7  Action  ( Paga  7  of  3) 


Primitive 

Ho.  Coda) 

Argument 

FTP  IUT  Action 

sica  (23) 


scat  (24) 


reao  (25) 


*.oop  (26) 


gat  (27) 


string 


pathname 


string 


remote-! 11a 
! local-file! 


-  Causes  the  User  FTP  to  sand  the  SITE 
commend  over  the  command  connection.  T-e 
Server  uses  this  command  to  provide  ser¬ 
vices  specific  to  its  system  essential  :o 
file  transfer  but  not  sufficiently  jni- 
varsal  to  be  Included  as  commands  in  the 
protocol.  The  nature  of  these  services 
and  the  specification  of  their  syntax  can 
be  stated  in  a  reply  to  the  R£MO  (remote 
help)  SITS  command. 

-  Causes  the  User  FT?  to  send  the  STAT 
command  over  the  command  connection. 

This  command  causes  a  status  resDonse  : : 
be  sent  over  the  command  connection  in 
the  form  of  a  reply. 

-  Causes  the  User  FTP  to  send  the  KEU? 
command  over  the  command  connection. 

This  command  causes  the  Server  to  send 
helpful  information  regarding  its  imple¬ 
mentation  status  over  the  command  con¬ 
nection  to  the  user.  The  command  -av 
take  an  argument  (e.g.,  anv  command  name 
and  recurn  more  soeciflc  information  as  i 
response.  The  reply  is  type  211  or  21- . 
(See  Section  5.7.3  of  MTL-S70-; 790. ) 

-  Causes  the  User  FT?  to  send  the  SOC? 
command  over  the  command  connection. 

This  command  does  not  affect  any  para¬ 
meters  or  previously  entered  commands. 

It  specifies  no  action  except  that  the 
Server  must  send  an  OK  reolv. 

-  Retrieves  the  remote-file  and  stores  it 
on  the  local  machine.  If  the  local-file 


.SCTTU:  Commands  27  through  32  have  no  eouivalent  in  hIL-STD- 1  73 0.  The v 
were  created  as  a  supersec  of  standard  FTP  commands  to  suooort 
driver  and  reference  functions  in  the  Protocol  Test  System. 
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Table  3.  Protocol  Primitive  CoMands,  lumber  Codas,  and  Arguments, 
with  Consequent  FTP  I’JT  Action  (Pag*  3  of  9) 


Primitive 

(Bo.  Code) 

Argument 

get  (27) 

remote-file 

(continued ) 

.'local-file 

.  ocal-fii# 
ramota-f lla  j 


■os :  port; 


-os:  .port 


argl  argl 


FTP  I'JT  Action 


name  Is  not  spaclflad,  the  file  la  given 
tha  same  naaa  It  has  on  the  remote 
machine.  Tha  gat  primitive  translates 
Into  tha  PORT  and  RJETR  FTP  commands  as 
specified  In  MIL-ST3-1 780. 


Stores  tha  local-file  on  the  remote 
machine.  If  remote-file  name  is  left 
unspecified,  the  local-file  name  Is  used. 
The  put  primitive  translates  into  the 
PORT  and  STOR  FT?  commands  as  specified 
in  MTL-STD-1780. 


Establishes  a  connection  to  the  specified 
host  FTP  Server.  An  ootlonal  jor.  -.umber 
nay  be  supplied,  In  which  case  :ne  .'ser 
FTP  will  attempt  to  contact  an  FT?  Server 
at  that  port. 


Switches  to  anv  soeclfled  host  that  -as 
already  been  connected.  A  oor:  number 
may  be  supolled  for  any  connection 
already  opened  using  the  ooen  command 
with  port  argument.  This  command  does 
not  send  any  data  across  the  command 
connection. 


Terminates  the  FT?  session  with  tne 
remote  Server  (an  ungraceful  close)  a-.c 
exits  Osar  FTP.  This  command  does  not 
send  any  data  across  tha  command  con¬ 
nection. 


Sends  the  arguments  argl  and  argC  to  :-e 
remote  FT?  Server  over  the  command  con¬ 
nection.  One  or  more  FTP  reply  coces  ire 
expected  In  return. 


■v-’-.-V'"  ,'\+ 
iaJ 


3. 3. 3. 2  The  Driver  Primitive  Codee 


If  che  control  flag  indicates  a  driver  command  ( : he  bit  In  ooeltion  3 
Is  sac  co  taro),  che  Reaoee  Driver  aaisc  cranslaca  cha  Integer  contained  In  ;ne 
coda  field  co  les  corresponding  driver  prlaldve  (Table  4).  The  HO  chan 
performs  che  appropriate  action,  as  specified  In  the  following  sections. 


Table  4.  The  Driver  Prlaiclvas 


Code 

Action 

0 

-  Kill  the  Remote  Driver  proeeae. 

l 

-  Send  associated  data  co  che  IUT. 

-  Coaoare  two  files  In  local  file  systea 

and  report  If  different. 

3. 3. 3. 2.1  The  KILL  Driver  Primitive.  If  the  Remoce  Driver  interprets  a 
driver  priaicive  code  of  3,  then  after  ACKing  che  driver  primitive  packet,  ;-.e 
process  oust  find  soaa  way  co  terminate  Itself.  So  ocher  action  Is  necessarv. 
The  Remoce  Driver  Is  not  responsible  for  conducting  a  graceful  snutdovn  o:  ;-.e 
orotocol;  Lt  is  che  responsibility  of  che  Central  Driver  to  cause  FT?  to  cult. 
The  HD  also  is  not  required  to  shut  itself  down  gracefully,  although  tnls 
action  Is  encouraged. 

3. 3. 3. 2. 2  The  DATA  Driver  Primitive.  This  command  is  used  wnen  testing 
requires  large  amounts  of  text  co  be  petted.  If  the  Remote  Driver  receives  a 
driver  primitive  code  of  l.  Indicating  the  DATA  commend,  then  after  ACKing  t-.e 
driver  priaicive  oecket,  the  RD  muec  send  the  text  portion  of  che  data  paexe: 
co  the  I  ITT  as  data.  The  ocher  fields  can  be  ignored. 


3. 3. 3. 2. 3  The  COMPARE  Driver  Primitive.  The  COMPARE  driver  primitive  is  use 
to  test  whether  the  FTP  I  IT  has  correctly  implemented  the  different  modes  of 
file  transfer.  When  the  Remote  Driver  receives  a  driver  primitive  code  of  2, 
indicating  the  COMPARE  driver  command,  then  after  ACKing  the  driver  primitive 
packet,  the  Remote  Driver  must  perform  a  compare  operation  on  the  two  files 
named  in  the  text  field  as  arguments  of  this  command.  If  the  files  are  found 
and  successfully  opened,  then  they  must  be  read  and  compared  by te-bv-by te .  I; 
the  two  files  are  exactly  alike,  then  the  Remote  Driver  must  return  a  data 
packet  containing  the  ASCII  equivalent  of  the  character  string  "success"  in 
the  text  field.  If  the  two  files  differ  by  even  a  bit,  however,  the  ASCII 
equivalent  of  the  character  string  "failure"  is  returned  to  the  Central  Drive: 
in  a  data  packet.  If  an  error  condition  occurs  (e.g.,  the  files  are 
nonexistent  or  cannot  be  opened),  then  the  Remote  Driver  must  also  send  back 
the  "failure"  string.  When  a  character  string  is  sent  back  in  a  data  packet, 
the  fields  should  contain  the  following  values: 


cntl  flac: 


nun  bvtes 


(indicating  a  driver  command); 

(indicating  DATA); 

(both  strings  have  7  bytes,  and  here  the  null- 
byte  string  terminator  is  not  necessary); 


success 


"failure"  (a  7-bvte  ASCII  character  string). 


3.4  ACK/NAK  PACKETS 


The  Remote  Driver  Is  required  to  acknowledge  the  receipt  of  every  driver 
or  protocol  command  (ACK  =  positive  acknowledgment;  NAK  =  negative 
acknowledgment).  When  it  is  able  to  read  and  interpret  a  packet  from  the  TCP 
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connection,  the  RD  sends  an  aCX  pack*:.  If  it  detects  an  error,  however,  tne 

Retort  :river  responds  with  a  SAX  packet.  The  RD  also  sends  a  SAX  oacxet  if  a 

reed  is  successful  Put  a  code  Is  unknovn,  or  some  ocher  field  is  in  error. 

The  following  values  indicate  ACX  or  SAX  packets: 

ACX  -  code:  0 

cncl_f lag :  Pi:  position  0  set  to  one  (1) 

Pic  position  2  set  to  one  (1)  if  protocol  command , 

to  zero  (0)  if  driver  command 

num  Pvtes:  0 


text : 


SAX  -  code: 


:ntl_flag: 


Pit  position  0  sec  to  zero  '0) 

Pit  position  2  set  to  one  (l)  if  protocol  command, 

to  zero  (0)  if  driver  command 


nun  Pvtes:  0 


text : 


3.5  TIMING 

it 

.  A  Remote  Triver  has  no  timing  constraints  per  se ,  Put  it  should  "oc  icd 

considerably  to  a  prococol  1'JT's  response  time.  For  example,  if  the  CTD  does 

V 

y  not  receive  a  data  packet  within  the  time  specified  in  a  script,  then  a 

w 

■3  timeout  condition  will  occur.  Such  a  condition  could  cause  an  ITT  to  fail  :*e 

test. 
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APPENDIX  B  -  GLOSSARY 


ACK  ( Acknowledgment ) 

In  data  transfer  between  devices,  data  is  blocked  into  units  of  a  size  given 
in  each  block's  header.  If  the  received  data  is  found  to  be  without  errors, 
then  the  receiving  device  sends  an  ACK  block  back  to  the  transmitting  unit  to 
acknowledge  receipt.  The  transmitting  device  then  sends  the  next  block.  If 
the  receiving  unit  detects  errors,  however,  it  sends  a  NAK  block  to  indicate 
the  received  data  contained  errors. 

ASCII  (American  Standard  Code  for  Information  Interchange) 

A  standard  code  for  the  representation  of  alphanumeric  information.  ASCII  is 
an  3-bit  code  in  which  7  bits  indicate  the  character  represented  and  the  3th, 
high-order  bit  is  used  for  parity. 

CTD  (Central  Test  Driver) 

DDN  (Defense  Data  Network) 


A  U.S.  military  packet-switched  network. 


DSC  (Digital  Equipment  Corporation) 


OoO  (Department  of  Defense) 

DTP  (Data  Transfer  Process) 

The  File  Transfer  Protocol  (FTP)  has  two  different  procaaa  ataeea  for 
data  tranafar.  TV. a  Server-DT?  (tha  actlva  acaca)  establishes  tha  data 
connaction  with  tha  listening  data  port,  sata  up  parameters  for  tranafar  and 
storage,  and  cranafara  data  on  command  from  lta  protocol  mtarprecar.  Tha 
"sar-DTP  (tha  paaalva  atata)  liscana  for  a  connaction  on  tha  data  port  from  a 
Server-FTP  procaaa. 

EBCDIC  (Extended  31nary-Codad  Decimal  Interchange  Coda) 

An  3-blt  code  for  repreaencing  alphanumeric  Information  within  a 
computer.  EBCDIC  la  moat  widely  uaad  In  large  computer  syatema.  fee  also 

ASCII. 

EDI  (Exploratory  Data  Network) 

FTP  (File  Transfer  Protocol) 

Tha  DoD  Interim  atandard  protocol  used  to  transfer  data  reliably  between 
hoata  on  DoD  packet-switched  networks. 
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IDT  (Implementation  Under  T«jc) 

A  given  vendor's  protocol  implementation  and  the  subject  of  the  immediate 

test. 

MIL- STD  (Military  Standard) 

Specification  published  by  the  DoD. 

MAC  (Negative  Acknowledgment) 

In  data  transfer  between  devices,  a  MAX  block  is  returned  by  the 
receiving  device  to  the  sending  device  to  indicate  the  preceding  data  block 
contained  errors.  See  also  ACX. 

packet  switching 

A  method  of  transmitting  messages  through  a  network  in  which  Long 
sassages  are  subdivided  into  short  oackets.  The  packets  are  then  transmitted 
as  in  message  switching. 

PAD  (Packet  Assembler/Disassembler) 

In  this  document,  PAD  refers  to  a  module  of  a  structured  program 
resoonsible  for  reading  and  writing  data  packets.  Not  to  be  confused  with 
other  kpown  usage,  which  describes  a  device  to  provide  service  to  asynchronous 
terminals  within  an  X.25  network. 


3-4 


PAX  ( Positive  Acknowledgment  and  Response) 

A  staple  communication  protocol  sctdng  thee  every  packet  received  uj: 
be  either  ACKad  or  HAKad. 

protocol 

A  set  of  rules  governing  the  operation  of  functional  units  to  achieve 
communication. 

TCP  ( Transmission  Control  Prococol) 

The  DoD  standard  connection-oriented  transport  prococol  used  to  provide 
reliable,  sequenced,  end-to-end  service. 

Telaec 

The  DoD  mcerla  standard  Virtual  Terminal  Prococol  for  the  flexible 
attachment  pf  remote  terminals  to  host  comouter  systems  over  the  network. 


APPENDIX  C  -  Examples  of  Remote  Driver  Implementation  in  L'N'IX'C 


C-l  CONNECTION  ESTABLISHMENT 

The  Remote  Driver  mast  be  able  to  establish  interprocess  communication;  i.e., 
to  read  and  write  data  stream  from  a  Transport  (TCP)  socket  or  from  the  FTP 
XUT.  Although  the  method  of  interprocess  communication  is  not  specified  for 
the  Remote  Driver,  a  description  of  how  a  Remote  Driver  is  implemented  may  be 
helpful.  (See  Figure  C.l). 

The  Protocol  Test  System  runs  in  a  UNIX  4.2  BSD  environment.  The  lab's  Remote 
Driver  is  implemented  in  C  language,  which  provides  access  to  several 
interprocess  communi cat  ion  system  calls  (e.g. ,  fork,  socket,  bind,  pipe, 
listen,  and  accept  system  calls). 

Specifically,  the  IUT  process  Is  activated  by  the  Remote  Driver  process  using 
the  fork  system  call.  This  forking  causes  a  parent-child  relathionship  to  be 
formed  between  the  two  processes.  Each  process  then  determines  whether  it  is 
the  child  or  the  parent.  If  the  process  is  the  parent,  then  it  exits. 

In  effect,  this  action  leaves  the  child  process  running  as  a  background 
process.  This  background  process  then  sets  up  the  TCP  socket  connection  by 
listening  passively  on  the  TCP  port  specified  in  Table  1. 
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After  che  TC?  connection  is  established,  the  Remoce  Driver  secs  jo 
communicat ion  with  the  I'JT  by  forking  another  process  and  setting  up 
interprocess  communication  through  the  use  of  the  pipe  system  call.  Dnce  :-.e 
pipes  are  established,  the  input/output  of  Che  two  processes  can  be 
manipulated  so  that  the  two  processes  end  up  communicating  with  each  other. 
Since  the  parenc  and  child  processes  are  exactly  the  same  (except  for  orocess 
identification  numbers)  and  would  be  useless  talking  to  themselves,  che 
prococol  I'JT  is  overlayed  onto  the  child  process  using  the  exec  system  call. 

When  chis  procedure  is  successfully  completed,  the  Remoce  Driver  — 
running  as  a  background  process  --  is  receiving  and  sending  data  over  che  TC? 
connection  on  one  side,  and  sending/receiving  data  to/from  the  prococol  I'JT  on 
the  ocher  side.  (See  Figure  I,  p.  3-2.) 

C .2  A  PAD  FUNCTION 

A  Packet  Asserabler/Dlsasserabler  (PAD)  funccion  is  useful  for  implementing 
a  Remoce  Driver.  Because  che  two  basic  functions  of  receiving  and 
transmitting  packets  are  performed  repeatedly,  it  may  be  wise  to  modularize 
them.  When  che  Remote  Driver  reads  data  from  the  command  channel,  it  must  be 
able  to  interpret  che  bytes  correctly.  In  a  UNIX/C  implementation,  che  mechod 
used  to  achieve  this  result  is  to  load  che  data  into  a  data  structure  where 
distinct  fields  can  be  declared.  In  C,  this  is  che  "struct”  declaration. 

Each  collection  of  fields  can  then  be  referenced  as  a  whole.  The  term 
"packet",  has  been  used  In  chis  document  as  che  name  of  this  data  structure 
reference.  The  "struct"  declaration  is  shown  in  Figure  C.2  (p.  C-4). 
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*  CONVECTION  ESTABLISHMENT  A. 2 BSD  CNIX/C  */ 

•'*  soawn  I'.T  process,  and  */ 

/*  put  this  process  lnco  background . . .  */ 

parenc  returns  p i d ;  child  returns  0  */ 

if  (  (fork_stat  -  fork())  >  0  )  *  pid  >  C* ' 

exit(  );  /*  so,  if  parent,  then  exit.  */ 

/*  else,  this  is  child,  so  continue!  */ 

pp  -  getprocobyname( "tcp” ) ;  /*  4.2  BSD  system  call  */ 


while  ((s  •  socket  (AF_INET,  SOCK_STREAM,  pp->p  proto))  <  0) 

{  if  (errno  !■  0)  ~ 

{  perror  (”FTP_SD:  socket”); 

sleep  (  1 ) ; 

} 

{ 

sin.sln_porc  -  sp->s_port;  /*  set  port  *  */ 

/*  bind  name  to  socket  */ 

while  (bind  (s,  (caddr  t)&sin,  sizeof  (sin),  0)  <  0) 

{  perror  ("FTP_SD:  bind"); 
sleep( 10) ; 

} 

Listen  (s,  10);  /*  passively  listen  on  socket  * 1 

/*  accept  connection  * 

s2  »  accept  (s,  (caddr_t )&frora,  ifromlen); 

/*  sec  up  pipes  */ 

if  (pipe(fdl)  <  0) 
return  (-1); 
if  (plpe( f d 2 )  <  0) 
return  (-1); 
in  pipe  -  fd  1  [ 0  )  ; 
out_pipe  *  fd2(  l  ] ; 

if  (fork(  )  ~  0)  /*  if  child  then  execute  the  following  *> 


{  close  (0);  /*  close  std  input  */ 

if  (dup2  (fd2(0],  0)  <  0  )  /*  open  R£AD  side  of  pipe  */ 

perror  ("dup2"); 

close  (1);  /*  close  std  output  */ 

if  ( dup2  (fdl( 1 ] ,  1)  <  0)  /*  open  WRITE  side  */ 

execl  ("/usr/iut/iuc  ftp”,  ”iuc  ftp”,  ”-v”,  ”-n”,  NoLL); 

> 


Figure  C.i. 


Outline  of  Connection  Establishment  in  4.2  BSD  CNIX/C 


'define  hAX_  TEXT_LEN  -»096 

struct  remot e_pa c<  ( 

char  cncl_f lag ; 
char  err  flag; 
inc  code; 
inc  num__bvtes; 

Inc  reserved; 

char  text [MAX  TEXT  LENj ; 


Figure  C.2.  The  C  Syntax  Format  of  the  Data  Packec 


The  reception  mode  of  the  PAD  function  reads  data  and  "packets"  the  data. 
The  PAD  accomplishes  this  task  by  reading  the  first  14  bytes  of  data  from  the 
input  stream.  This  first  14  bytes  is  effectively  the  header  of  the  data  oack- 
et.  It  contains  all  the  information  needed  to  process  the  packet,  including 
the  integer  in  the  "num_byces"  field  that  indicates  the  number  of  bytes  of 
character  text  to  follow  --  if  any. 


The  transmission  mode  of  the  PAD  function  unpackecs  the  data  and  sends 
data  over  the  communication  channel.  The  PAD  accomplishes  this  task  by 
reading  the  header  of  the  packec  and  wricing  the  information  into  a  memory 
space  allocated  for  a  large  character  string.  The  size  is  equal  to  4096 
bvtes  —  the  maximum  text  size  —  plus  14  bytes  for  the  header  information. 
If  the  cexc  size  is  less  than  the  maximum,  then  only  chac  much  need  be  writ 
cen.  The  Remote  Driver  must  transmit  che  data  as  a  normal  byte  scream.  If 
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the  input  daca  stream  is  correctly  packeted  into  a  data  structure,  then  inter¬ 
pretation  of  the  fields  in  the  packet  should  become  clearer  and  less  suscep¬ 
tible  to  error.  An  example  of  a  PAD  implemented  in  C  is  given  in  Figure  C.3 
( p .  C-  5 ) . 
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••'define  HEADER  SIZE  in 
"define  MAX_TEXT_LEN  -096 

"define  MAX~P A  CK  LEX  HEADER  SIZE-MAX  TEXT  LEN 


send_packet(packet ,sock)  /*  packet  disassembler 

struct  remote_pack  ‘packet; 
int  sock; 

{  register  int  i; 

char  send_buf fer (MAX  PACK  LENT ]  ; 


} 


send_buffer(0)  -  packet->cntl_f lag ; 
send__buf  fer  (  1  ]  *  pa  eke  t->err_f  lag  ; 

*((inc  *)(send_buffer-2) )  ■  packet->code ; 

*((int  *)(send_buf fer-6) )  ■  packet->num  bvtes; 

*((int  *)(send_buffer-lO) )  -  packet->reseYved ; 

fo r( i-0 : i<pack7t->nura  bytes; i*-) 

send^buf  fer(  1-mT  *  packet->text [  l  ]  ; 

/*  send  the  packet 
ret  urn (write( sock,  send_buffer, 

packec->num_bv tes-HEADER  SIZE)); 


*/ 


*/ 


recv_oackec(packec, sock)  /*  oacket  assembler  */ 

struct  remote_oack  ‘packet; 
int  sock; 


1 


char  recv_buffer( HEADER  SIZE); 
int  result; 


if 

f 


/*  read  the  header  */ 

(result  -  read(sock,  recv__buf  fer,  HEADER_SIZE) )  !- 

HEADER  SIZE) 


return 


( result) ; 


packet->cntl__f lag  •  recv_buffer(0) ; 
packet->err_7lag  -  recv~buf fe r [ l ) ; 
packet->cod7  -  ‘((Int"*)  (recvjsuf  fer-2) ) ; 
packe t->nuo<_bytes  ■  *((int  *)  (r7cv  buffer-6)); 
packet->res7rved  -  ‘((int  *)  ( recv”buff er-10) ) ; 

/*  read  the  text  */ 

if  (packet->nuo  bytes) 

{  ~ 

if ( read! sock ,  packet->text ,  packet->num_by tes )  !- 

packet->num_bytes) 

return(-l);  ” 

} 

return( 0) ; 


} 


Figure  C.3,  A  Packet  Asstmbler/Dlsassembler  in  C 


